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This paper discusses the Structured Query Language (SQL) injection attack technique and offers 
mitigation methods. 


Overview 

Structured Query Language (SQL) injection is an attack technique that attempts to subvert the 
relationship between a webpage and its supporting database, typically in order to trick the 
database into executing malicious code. SQL injection usually involves a combination of over¬ 
elevated permissions, unsanitized/untyped user input, and/or true software (database) 
vulnerabilities. Since SQL injection is possible even when no traditional software vulnerabilities 
exist, mitigation is often much more complicated than simply applying a security patch. 

Background 

In 2008, there was a significant increase in the number of websites affected by SQL injection 
attacks. This increase can be attributed in part to the development of automated tools that 
allowed attackers to test and compromise sites much faster than older manual methods. 
Eventually, this functionality was included in botnets which used SQL injection attacks to grow 
the size of the botnet. Another significant contributing factor to this increase is due to the 
synergy that exists between malware toolkits, such as MPack, and widespread SQL injection 
attacks. MPack and other malware kits can be configured to exploit a variety of potential 
vulnerabilities, which increases the likelihood of a successful attack. Conducting SQL injection 
attacks against a large number of sites increases the number of visitors to the malware kit, which 
multiplies the return on investment for the attacker. 

The following are specific examples of SQL injection events that occurred in 2008: 


• April 2008 - attacks against Microsoft Internet Information Services (IIS) that affected 
more than half a million websites 

• December 2008 - Microsoft Internet Explorer 7 (IE7) 0-day exploit that was leveraged 
via SQL injection attacks 
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Detection 


Detection of SQL injection attacks can be attempted with Webserver log auditing combined with 
network Intrusion Detection Systems (IDS). If you run a production Webserver, you must enable 
logging and periodically review these logs. Numerous software tools exist that allow for the 
rapid search of Webserver logs for specified keywords or regular expressions. Typical searches 
include commands and characters that should not normally be provided by a user, such as 
"EXEC", "POST", "UNION", "CAST", or a single quotation mark. While there are many 
potential searches, each will be useful only in the proper context since valid web forms that 
require the use of these commands have the potential to generate false positives. 

Comprehensive detection of SQL injection attacks is very difficult. Even with logging enabled 
on all production webservers and Intrusion Detection Systems (IDS) on network chokepoints, the 
number of methods that attackers can use and combine to evade detection is daunting. For 
instance, attackers can manipulate the whitespace between commands, encode using decimal, 
HEX, BASE64, etc., and even inject characters that the Webserver / database will ignore in order 
to evade detection by IDS or log-based analysis. 

Prevention is the best approach. 

Mitigation/Best Practices 

The following mitigation strategies and best practices can be used to minimize the risks 
associated with this attack vector: As with any system or architecture changes, local 
administrators are best positioned to know which strategies are appropriate for their specific 
networks and systems. 

Network Level Recommendations 

• Deny access to the internet except through proxies for Store and Enterprise servers and 
workstations. 

• Implement firewall rules to block or restrict internet and intranet access for database 
systems. 

• Implement firewall rules to block known malicious IP addresses. 

• Harden internal systems against the potential threat posed by a compromised system on 
the local network. (Do not rely on firewalls to prevent access to insecure systems; secure 
them.) 


System / Application Level Recommendations 

• Secure both the operating system and the application. 

o Consider using NIST or other industry standard security checklists to harden both the 
operating systems and the applications 
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o Run only the minimum required applications and services on servers necessary to 
perform their intended function. In other words, disable all unnecessary applications 
and services. 

o Follow application vendor security guidelines. 

• Update and patch production servers regularly. 

o Include both operating system patches and application patches. 

• Disable potentially harmful SQL stored procedure calls. 

° ‘xp cmdshell’ on MSSQL has been frequently used by attackers. 

• Deny extended URLs. 

o Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail 
to log the complete request. Unless specific applications require long URLs, set a 
limit of 2048 characters. Microsoft IIS will process requests over 4096 bytes long, but 
will not place the contents of the request in the log files. This has become an 
effective way to evade detection while performing attacks. 

• Sanitize/validate input. 

o Ensure data is properly typed, 
o Ensure data does not contain escaped code. 

o Consider using type-safe stored procedures/prepared statements. 

• Ensure error messages are generic and do not expose too much information. 

o Keep error messages short and usable. 

o Do not disclose internal database structure, table names, or account names. 

• Use principles of least privilege. 

o Install and run authorized Microsoft SQL Server and IIS services under a non- 
privileged account. 

o Apply the principle of 'least privilege' on all SQL machine accounts, 
o Remove guest accounts unless operationally necessary. 

o Use an application account for database access. 

• Enforce best practice password and account policies. 

o Require the use of a password on Microsoft SQL Server administrator, user, and 
machine accounts. 

o Change default/built-in account passwords, 
o Change application account passwords regularly, 
o Use strong passwords. 

o Lock out accounts after several unsuccessful logon attempts. 

• Document all database accounts, stored procedures, and prepared statements along with 
their uses. 

o Delete/disable unnecessary accounts (including default accounts). 
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o Delete/disable unnecessary stored procedures/prepared statements. 

• Perform regular audits and penetration testing. 

o Audit transaction logs for suspicious activity. 

o Audit group and role memberships to ensure enforcement of least access principles, 
o Audit stored procedures on a regular basis and remove unnecessary ones, 
o If you use ASP, consider using Microsoft’s code analyzer, 
o Consider using HP’s scrawlr utility to help identify problems, 
o Conduct penetration tests against applications, servers, and perimeter security. 

Additional Resources 

ASP.NET SQLI Prevention 

http://msdn.microsoft.com/en-us/library/ms998271 .aspx 

National Vulnerability Database (NVD) Security Checklists 
http://checklists.nist.gov/ncp.cfm7prod category 

Open Web Application Security Project (OWASP) SQLI page: 
http://www.owasp.org/index.php/SQL Injection 

Mysql guide to PHP security (ch3 SQL Injection) 

http://dev.mvsql.com/tech-resources/articles/guide-to-php-securitv-ch3.pdf 

Mysql article on Prepared Statements 

http://dev.mvsql.eom/tech-resources/articles/4.l/prepared-statements.html 
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